… chain

Context::record_for_hash walked every record in the block log to find one. The
log holds one entry per applied block and nothing removes it, so at a mainnet tip
that is ~963k comparisons per call -- and getblock, getblockheader and the index
read path all land there. It is the same shape as the gettxoutproof scan, on a
hotter path.

Step 1 already knows the height, because the block tree gave it. That makes the
lookup a binary search over a height-ordered log. The log is append-only in
height order -- add_block pushes, and the only removal is the tail pop a
disconnect performs on the applied tip -- and the codebase already relied on that:
crates/node had record_at_height and record_at_height_hash doing exactly this.

Rather than copy them, they move to crates/rpc beside BlockRecord and node imports
them, so one implementation serves both and forty lines of duplicate go away.
Context::block_by_height and Context::block_hash_at_height were scanning the same
way and now use them too.

Step 2 stays linear on purpose. Without the tree there is no height to search on,
and a hash-keyed index would have to be maintained for every block to serve a path
only legacy state reaches. The comment says so.

Three tests cover the parts the rpc side never had: that a hash is matched within
a duplicate-height run rather than the run's first record being assumed, that a
hash absent from the run does not resolve to a sibling, and that a log which does
not start at height zero still resolves.

The duplicate-height test is shaped deliberately. Heights [1, 1, 2] put the dense
fast path's index straight onto the second duplicate, where the height check alone
would accept it and only the preceding-record guard rejects it. An earlier version
used heights starting at zero, passed, and did not touch the guard at all -- the
mutation audit caught that the test was not testing what its name claimed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…factor

Both conflicts were additive, not semantic: the crate root export list gained
entries on each side, and the block-source file gained a BlockTreeAdapter impl on
main where this branch had deleted the duplicate lookup helpers. The merge
resurrected those helpers alongside the import that replaced them, so they are
deleted again here.

The premise still holds after the refactor: record_for_hash on the new main still
walks the log linearly in all four places this branch replaces.

Re-ran the mutation audit rather than trusting the tests for staying green
through a merge that moved the code they pin. Both mutations still turn the
intended tests red. One change is worth noting: under the hash-ignoring mutation
node used to fail a test too, and no longer does -- main routing that path through
BlockTreeAdapter cost node its detector. The rpc side still catches it twice.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The PR claimed a performance win with no number attached. This adds the
refactor-set benchmark, both arms over one fixture in one process.

  10,000 records, hash at tip:     12.17 us -> 39.6 ns       307x
  100,000 records, hash at tip:   415.90 us -> 50.2 ns     8,285x
  500,000 records, hash at tip:     3.737 ms -> 46.1 ns   81,092x
  963,124 records, hash at tip:     7.707 ms -> 48.3 ns  159,569x
  963,124 records, hash in middle:  3.328 ms -> 48.6 ns   68,528x

The new arm is flat at 37-50 ns across 96x the records: a binary search is ~20
steps at a mainnet tip. Two lookup positions are measured because reporting one
would flatter the scan - the tip is its worst case, the middle costs it half.

The linear scan is written out in the benchmark and in the new tests rather than
called through the crate: it is two lines, and an oracle that shares code with
the implementation cannot disagree with it.

Three tests are added on top of the three already here. Two sweep the search
against that scan over every height in and around the fixture and every hash in
it - a search is wrong at its boundaries, and a test that picks one pair picks
whether it visits them. The third covers `block_by_height` with no applied tip,
which was a gap: replacing that fallback's whole body with "the last record in
the log" turned nothing red, and the new test is the only one that kills it.

The shared fixture starts at height 1 rather than 0. That is load-bearing: the
preceding-record guard in the direct-index fast path only matters when index `h`
holds a record at height `h` that is not the first at that height, and a log
starting at zero can never be in that state.

Re-audited at seven mutations, all killed, baseline and restored green. Write-up
in docs/benchmarks/block-record-lookup.md.

Ported from perf/chaininfo-fold, where the same change was written a second time
before this PR was noticed. That copy is reverted; this is the one that stays.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>